Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000017_owner-urn-ietf _Fri Aug 16 16:30:45 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA20312 for urn-ietf-out; Fri, 16 Aug 1996 16:30:45 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA20307 for <[e-mail]>; Fri, 16 Aug 1996 16:30:40 -0400
Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA26851  (mail destined for [e-mail]); Fri, 16 Aug 96 16:30:31 -0400
Received: from void.ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id PAA23561; Fri, 16 Aug 1996 15:30:17 -0500
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA07371; Fri, 16 Aug 96 15:26:41 CDT
Date: Fri, 16 Aug 96 15:26:41 CDT
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: Ron Daniel <[e-mail]>
Cc: [e-mail]
Subject: [URN] revision of NAPTR draft
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail] (Daniel LaLiberte)
Errors-To: [e-mail]

Ron Daniel writes:
 > This draft does not incorporate Lewis Girod's suggested replacement
 > for regexps. I would like to see some more discussion on the list
 > of that topic.

I don't have much to say about Lewis Girod's suggestion - I rather
like regular expressions and don't think they will be a problem for
what the do offer.

However, I am concerned because of features I know regular expression
lack.  In particular, there is a need to be able to reverse a list of
component names in the construction of a DNS name, because DNS uses
one order for components (i.e. most specific component to most
general, e.g. small.big.bigger.biggest.) whereas some names systems
might order components in the other order (e.g. the path scheme).
Regular expressions do not support the idea of reversing an arbitrary
number of elements.

One way around this obstacle is to add some features beyond (or
outside of) normal regular expression.  Three things are needed here.
A way to specify the components of the list, a way to specify that the
list should be reversed, and a way to concatenate the elements of the
list with the "." separator.  The list of elements might be specified
by parentheses.  E.g.  #(/([^/])*)*# matches a path such as /a/b/c
with the inner parentheses matching each of the components.  To
reverse the list, an "r" might be appended to the regular expression.
The replacement might assume that the constructed DNS name takes the
elements of the list, with the option of reversing them, and joins
with the "." separator.  There are some problems with this scheme that
I'll let others point out - maybe they have solutions too.

In previous discussion with Ron, he suggested that it might be
possible to use the resolution algorithm, as is but iteratively, to
bite off a component at a time and construct the reversed DNS name.
This sounds similar to what we recommend for the path scheme
resolution in the first place, so I would be happy to go with it - it
wouldnt require a list reversal extension.  But I don't see how it can
be done.  Could you give an example of how this works?

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/